home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 6 / CU Amiga Magazine's Super CD-ROM 06 (1996)(EMAP Images)(GB)(Track 1 of 4)[!][issue 1997-01].iso / cucd / online / fidonetts / fsc-0057.003 < prev    next >
Text File  |  1992-12-07  |  20KB  |  513 lines
  1. Document: FSC-0057
  2. Version:  003
  3. Date:     07-Dec-92
  4.  
  5.  
  6.  
  7.  
  8.                Conference Managers - Specifications for Requests
  9.  
  10.                                December 7, 1992
  11.  
  12.                    Fabiano Fabris      Joaquim H. Homrighausen
  13.                 2:285/304.100@fidonet      2:270/17@fidonet
  14.  
  15.  
  16.  
  17.  
  18.     Status of this document:
  19.  
  20.     This FSC suggests a proposed protocol for the FidoNet(r) community, and
  21.     requests discussion and suggestions for improvements. Revision 3
  22.     presents several additions and enhancements over the previous revision.
  23.  
  24.     Distribution of this document is unlimited.
  25.  
  26.     Fido and FidoNet are registered marks of Tom Jennings and Fido
  27.     Software.
  28.  
  29.  
  30.  
  31.     1  Purpose
  32.  
  33.        This document will explore the methods implemented by various
  34.        conference managers which process requests (in net mail form)
  35.        for changes to the conference mail links on the system on which
  36.        they are in use.
  37.  
  38.        Until now, it would appear that no real standard exists, so most
  39.        software authors have either tried to emulate another program, or
  40.        to create a new method of their own, or both.
  41.  
  42.        Here, an attempt will be made to define a standard, one which tries
  43.        to maintain compatibility with methods already in use, while also
  44.        extending them to provide new functions.
  45.  
  46.  
  47.  
  48.     2  Conventions
  49.  
  50.        The names of the commands described in the following paragraphs are
  51.        given in upper case, for legibility. However, a conference manager
  52.        should be able to interpret them even if they are given in lower
  53.        or mixed case.
  54.  
  55.        Similarly, conference names, or tags, are given in upper case, but
  56.        the conference manager should be able to handle them even if typed
  57.        in lower or mixed case.
  58.  
  59.        Optional information is enclosed with square brackets, while
  60.        variable information is enclosed with angle brackets. For example:
  61.  
  62.           +CONF [,R=<n>]
  63.  
  64.        indicates that the section within square brackets is optional, and
  65.        if supplied, requires a parameter after the equals sign.
  66.  
  67.        Some conference managers may allow commands to be abbreviated to the
  68.        shortest non-ambiguous string. For example, %LIST might be reduced
  69.        to %L.
  70.  
  71.  
  72.  
  73.     3  Format of the request
  74.  
  75.        A request to a conference manager is generally made in a net mail
  76.        message containing specific information in some of the fields. In
  77.        particular, the addressee is the name of the conference manager
  78.        itself, and the subject of the message is a password assigned by
  79.        the sysop of the system running the program.
  80.  
  81.        For example:
  82.  
  83.           From:     John Doe, on 2:123/56
  84.           To:       Program,  on 2:234/0
  85.           Subject:  password
  86.  
  87.        Here the first problem is encountered. Each of the existing programs
  88.        recognizes a different addressee. For this reason it is proposed
  89.        that all such programs recognize requests made to a single,
  90.        "standard" addressee, besides any other they may wish to implement.
  91.        The term "ConfMgr" has been arbitrarily chosen, and should be used
  92.        by those programs which adhere fully to all the standards proposed
  93.        in this document.
  94.  
  95.        The text of the message itself contains the request proper, and is
  96.        the subject of the following paragraphs.
  97.  
  98.  
  99.  
  100.     4  Linking and Unlinking of conferences.
  101.  
  102.        The current methods for requesting that a conference be linked are
  103.        basically two:
  104.  
  105.           +CONFNAME
  106.           CONFNAME
  107.  
  108.        For reasons of uniformity, it is proposed that all conference
  109.        manager programs recognize the first method.
  110.  
  111.        Requests that a conference be unlinked are given by:
  112.  
  113.           -CONFNAME
  114.  
  115.        It might be interesting to implement some form of pattern matching,
  116.        similar to the unix shell. The following basic wildcards should be
  117.        considered:
  118.  
  119.           *        matches zero or more characters
  120.           ?        matches any one (not zero) character
  121.  
  122.        Since the requests are processed top-down, a request of the form
  123.  
  124.           +CONFNAME
  125.           -*
  126.  
  127.        would be redundant, since the ConfMgr would link CONFNAME from the
  128.        first line, and then immediately unlink it again because of the
  129.        second line, which requests that all linked conferenecs be unlinked.
  130.  
  131.        It should also be possible to specify more than one conference tag
  132.        on the same line. For example:
  133.  
  134.           +CONF1 CONF2 CONF3
  135.  
  136.        would link the three conferences CONF1, CONF2 and CONF3.
  137.  
  138.  
  139.  
  140.     5  Rescanning Conference Mail
  141.  
  142.        Many conference managers currently allow a system to request that an
  143.        area be "rescanned". In other words, the system receiving the
  144.        request will export all mail in one or more areas to the requesting
  145.        system.
  146.  
  147.        This may be accomplished by specifying the %RESCAN command in the
  148.        body of the request. This will force the ConfMgr to generate a scan
  149.        request for those areas which the remote system requested with the
  150.        message containing the %RESCAN command.
  151.  
  152.        Rescans of a single area, newly linked, could be requested as
  153.        follows:
  154.  
  155.           +CONFNAME, R[=<n>]
  156.  
  157.        where 'n' is the number of messages in that area to be rescanned.
  158.        (The space following the comma is optional, but allowed.)
  159.  
  160.        Rescanning has one serious drawback: dupes! It is very possible for
  161.        the requesting system to have already set up the area with several
  162.        downlinks. Thus, when the rescanned mail is received, it could be
  163.        exported to other systems. In a tree-based topology, this is
  164.        harmless, but in circular topologies this would create dupes.
  165.  
  166.        Thus, it is proposed that system receiving the rescan request add a
  167.        kludge to the messages, so that they can be recognized by the
  168.        requesting system and not re-exported.
  169.  
  170.        The proposed kludge is:
  171.  
  172.           ^ARESCANNED <addr>
  173.  
  174.        where <addr> is the network address, including domain, of the
  175.        system from which the mail was rescanned.
  176.  
  177.        In alternative to a rescan, a sysop might request a "sample",
  178.        consisting of a series of messages contained in a text file. The
  179.        ConfMgr would export some or all messages from an area to a plain
  180.        ASCII text file, and send it along with the reply, to the requesting
  181.        system. A "sample" request would be made as follows:
  182.  
  183.           +CONFNAME, S[=<n>]
  184.  
  185.        where 'n' indicates how many messages should be sampled.
  186.  
  187.        a) Updating Conferences
  188.  
  189.           Update requests allow a sysop to rescan or "sample" an area
  190.           without having to first unlink from it, and then relink with the
  191.           rescan or "sample" parameter.
  192.  
  193.           The format of this command is:
  194.  
  195.              =CONFNAME, <param>[=<n>]
  196.  
  197.           Thus a rescan request for the most recent 50 messages would be
  198.           specified as:
  199.  
  200.              =CONFNAME, R=50
  201.  
  202.  
  203.  
  204.     6  Information Requests
  205.  
  206.        Requests for information have until now taken two forms. In one
  207.        case, they are given as switches after the password on the subject
  208.        line, while in the second they are given as "commands" within the
  209.        body of the message text. It is proposed that the second method be
  210.        chosen as standard, since it is considerably more flexible.
  211.  
  212.        Below are listed the proposed commands:
  213.  
  214.          %HELP                    Sends a (pre-defined) help text to the
  215.                                   requesting system, explaining how the
  216.                                   ConfMgr is to be used.
  217.  
  218.          %LIST[,B]                Lists the conferences currently available
  219.                                   to the requesting system, on the basis
  220.                                   of a method internal to the conference
  221.                                   manager itself. This list would flag the
  222.                                   areas which are already linked. The 'B'
  223.                                   modifier would generate the list in
  224.                                   binary format (see section 8e).
  225.  
  226.          %BLIST                   Equivalent to %LIST,B above.
  227.  
  228.          %QUERY                   Lists the conferences currently linked to
  229.                                   the requesting system.
  230.  
  231.          %UNLINKED                Lists the conferences which are available
  232.                                   to the requesting system, but not
  233.                                   currently linked. This is the logical
  234.                                   difference between a %LIST and a %QUERY.
  235.  
  236.  
  237.  
  238.     7  Remote Maintenance
  239.  
  240.        Besides these simple functions, it is becoming more and more
  241.        interesting to make handling of the conference mail flow even more
  242.        automatic. For this reason, for example, it might be useful to
  243.        allow another sysop control over your own system, adding and
  244.        removing conferences as need requires. Thus a hub or coordinator
  245.        could automatically have a new area added to their conference
  246.        lists, or discontinued ones removed.
  247.  
  248.        Naturally, the ConfMgr must be able to distinguish which system has
  249.        the ability to make such changes, but that is beyond the scope of
  250.        this document.
  251.  
  252.        It is proposed that a conference manager be able to automatically
  253.        add a new conference to the system's list if/when it is detected.
  254.        Thus no special commands would be required. The manager should be
  255.        able to determine a default list of down-links for the new area,
  256.        and also the "group" of systems which could then request it.
  257.  
  258.        However, should it be desired to explicitly create a new conference
  259.        via remote, this could be done by including a line such as the
  260.        following in the message text:
  261.  
  262.           &CONFNAME
  263.  
  264.        In order to remote delete an area, the requesting sysop should
  265.        include a line like this in the body of the message text:
  266.  
  267.           ~CONFNAME
  268.  
  269.        Thus, if the system has remote privileges, the conference would be
  270.        deleted (and optionally, all systems linked to the conference could
  271.        be informed of this fact).
  272.  
  273.        Similarly, it would also be possible to allow a system to change the
  274.        tag of a conference. This would be accomplished by a line such as:
  275.  
  276.           # OLD_NAME  NEW_NAME
  277.  
  278.        The ConfMgr should inform all downlinks of the change by sending a
  279.        net mail message.
  280.  
  281.        It might also be desirable to allow a sysop to make changes on
  282.        behalf of another system. This could be done by inserting a special
  283.        command at the beginning of the request itself. For example:
  284.  
  285.           From:     John Doe, on 2:123/1
  286.           To:       Program,  on 2:987/65
  287.           Subject:  password
  288.           Text:
  289.           %FROM: 2:234/56
  290.           +CONFNAME
  291.  
  292.        The %FROM command would make the ConfMgr carry out the changes as if
  293.        the system 2:234/56 had requested them. The password should
  294.        nonetheless be the one assigned to 2:123/1.
  295.  
  296.  
  297.  
  298.     8  Further Automation
  299.  
  300.        In order to make the system more powerful, and to reduce the
  301.        necessity for human intervention, several extensions are feasible.
  302.  
  303.        a) ARCmail Compression Method
  304.  
  305.           One interesting application is the possibility of allowing a
  306.           remote system to change the compression program used to "pack"
  307.           mail bound for his system. This could be done with the following
  308.           command in the message to a ConfMgr:
  309.  
  310.              %COMPRESS <method>
  311.  
  312.           where <method> is one of the compression programs supported by
  313.           the system. Of course, the remote system should also be able to
  314.           determine which compression methods are available; this could be
  315.           done with
  316.  
  317.              %COMPRESS ?
  318.  
  319.           Requests for an unsupported compression method should also be
  320.           responded to with a list of those available.
  321.  
  322.           From the practical point of view, only systems which pick up
  323.           their mail (as opposed to those to whom mail is sent) should be
  324.           allowed to change the compression method used. How this
  325.           distinction is achieved is beyond the scope of this document.
  326.  
  327.        b) Passwords
  328.  
  329.           A sysop should be able to change the password used to make
  330.           requests to a ConfMgr without requiring the intervention of the
  331.           other system's sysop. This could easily be done if the
  332.           conference manager implemented the following command:
  333.  
  334.              %PWD <new_password>
  335.  
  336.           The new password (case insensitive) would replace the current
  337.           one as of the next request.
  338.  
  339.        c) Temporary Unlink
  340.  
  341.           Should a system's sysop be absent for a prolonged period of time,
  342.           he might want to temporarily cut all conferences from his
  343.           uplink.  This could be accomplished with the
  344.  
  345.              %PAUSE
  346.  
  347.           command. This would tell the ConfMgr to temporarily stop sending
  348.           conferences to that system.  On his return, the sysop could
  349.           reactivate them all with the
  350.  
  351.              %RESUME
  352.  
  353.           command.
  354.  
  355.        d) Forwarding Remote Requests
  356.  
  357.           If a conference manager receives a remote request to delete an
  358.           area, it could very easily "forward" that request to all its
  359.           downlinks by producing a similar request.  In that way, a single
  360.           request originating from, for example, a Region Coordinator,
  361.           would result in the conference being deleted from all systems
  362.           "below" him.
  363.  
  364.           Similarly, remote requests for conference name changes could
  365.           also be passed on to downlinks.
  366.  
  367.        e) Automatic Requests for Conferences
  368.  
  369.           A conference manager should also be able to automatically request
  370.           an area from an uplink. This would become necessary if, for
  371.           example, it processed a request for an area not currently
  372.           available on the system. In this case, it would scan a series of
  373.           conference lists for the requested area, and if found, would
  374.           send a request for that area.
  375.  
  376.           In order to be able to do this, the ConfMgr would need to have
  377.           one or more lists of conferences from the uplinks. These lists
  378.           could be produced on request by the ConfMgr itself. In order to
  379.           simplify matters, a binary format is proposed. (Note that these
  380.           are C-style structures, with everything which that implies.)
  381.           This binary file is called a Binary Conference List (BCL).
  382.  
  383.           The file starts with a header, containing some basic system
  384.           information:
  385.  
  386.              struct bcl_header {
  387.                char    FingerPrint[4];     /* BCL<NUL> */
  388.                char    ConfMgrName[31];    /* Name of "ConfMgr" */
  389.                char    Origin[51];         /* Originating network addr */
  390.                long    CreationTime;       /* UNIX-timestamp when created */
  391.                long    flags;              /* Options, see below */
  392.                char    Reserved[256];      /* Reserved data */
  393.              }
  394.  
  395.           The currently defined flags for the header are:
  396.  
  397.             BCLH_ISLIST     0x00000001L
  398.               File is complete list
  399.  
  400.             BCLH_ISUPDATE   0x00000002L
  401.               File contains update/diff information
  402.  
  403.           The BCL would then contain a series of entries having the
  404.           following format:
  405.  
  406.              struct bcl {
  407.                int     EntryLength;      /* Length of entry data */
  408.                long    flags1, flags2;   /* Conference flags */
  409.                char    *AreaTag;         /* Area tag [51] */
  410.                char    *Description;     /* Description [51] */
  411.                char    *Administrator;   /* Administrator or contact [51] */
  412.              }
  413.  
  414.           The flags currently defined are:
  415.  
  416.              FLG1_READONLY   0x00000001L
  417.                 Read only, software must not allow users to enter mail.
  418.  
  419.              FLG1_PRIVATE    0x00000002L
  420.                 Private attribute of messages is honored.
  421.  
  422.              FLG1_FILECONF   0x00000004L
  423.                 File conference.
  424.  
  425.              FLG1_MAILCONF   0x00000008L
  426.                 Mail conference.
  427.  
  428.              FLG1_REMOVE     0x00000010L
  429.                 Remove specified conference from list (otherwise add/upd).
  430.  
  431.           Thus, instead of scanning an AREAS.BBS style list, the ConfMgr
  432.           would parse and use lists in the above format. Naturally, each
  433.           list would be in some way "attached" to a node number, and a
  434.           corresponding ConfMgr password.
  435.  
  436.           Each system may only have one master file, called anything they
  437.           want. But when transmitted to other systems, this file must
  438.           always be named ????????.BCL.
  439.  
  440.           The list would be generated in response to a
  441.  
  442.             %LIST, B
  443.  
  444.           command in the message text.
  445.  
  446.        f) Receipts
  447.  
  448.           It might be useful to have the ConfMgr generate a receipt to be
  449.           sent to another system, perhaps a co-sysop or a sysop point
  450.           node. This could be done with the command:
  451.  
  452.             %RECEIPT <name>,<address>
  453.  
  454.          embedded in the request message. For example:
  455.  
  456.             %RECEIPT JoHo,2:270/17
  457.  
  458.  
  459.  
  460.     9  Comments in the request
  461.  
  462.        It should be possible for a sysop to insert a comment in the request
  463.        made to a conference manager. These comments, naturally, would be
  464.        destined to the sysop of the system, and not to the conference
  465.        manager itself. Such comments should be placed at the end of the
  466.        message, following a %NOTE command.
  467.  
  468.        In all cases except the above, the request can be deleted by the
  469.        ConfMgr once processed, but messages containing comments should be
  470.        retained.
  471.  
  472.        Note: the current method used is to supply comments after a tear-
  473.        line. This practice is somewhat "messy", but it might be wise to
  474.        support it until such time as all conference managers have
  475.        implemented the %NOTE command.
  476.  
  477.  
  478.  
  479.     10 Summary
  480.  
  481.        +CONFNAME[,R|S]        Request to link to CONFNAME
  482.        -CONFNAME              Request to unlink from CONFNAME
  483.        =CONFNAME,R|S          Rescan or "sample" linked conference
  484.        &CONFNAME              Request to create CONFNAME
  485.        ~CONFNAME              Request to delete CONFNAME
  486.        #OLD NEW               Name change request
  487.  
  488.        %LIST[,B]              List available areas, flag linked
  489.        %QUERY                 Only list linked areas
  490.        %UNLINKED              List available but unlinked areas
  491.        %HELP                  Send help text
  492.        %FROM <addr>           Simulate request from another system
  493.        %RESCAN                Rescan conferences linked in current request
  494.        %COMPRESS <method>     Change compression method
  495.        %PWD <new_pwd>         Change ConfMgr password
  496.        %PAUSE                 Suspend link
  497.        %RESUME                Resume link
  498.        %RECEIPT <name>,<addr> Send copy of receipt to another system
  499.        %NOTE                  Introduces comment to the sysop
  500.  
  501.  
  502.  
  503.     11 Final Note
  504.  
  505.        This document is to be considered as a suggestion for software
  506.        developers to make their programs compatible with one another, so as
  507.        to make life easier for the average sysop when dealing with
  508.        conference managers.
  509.  
  510.        Feedback would be appreciated and can be sent to us at the addresses
  511.        specified on the title page. Please send feedback via netmail only.
  512.  
  513.